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 .
Double Patenting
The non-statutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A non-statutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on non-statutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a non-statutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Instant application 19/189,204
US 12299162 B1
1. A method, comprising:
identifying or determining, by one or more processing circuits, one or more endpoints;
mapping, by the one or more processing circuits, in a data package, access information of the one or more endpoints to a structure corresponding to one or more endpoint requests to access the one or more endpoints, wherein the one or more endpoint requests correspond with requesting cyber resilience data corresponding to at least one of a cybersecurity metric, incident data, compliance information, or operational data of an entity or third-party;
performing, by the one or more processing circuits using the data package, a request corresponding to at least one endpoint request of the one or more endpoint requests;
receiving or identifying, by the one or more processing circuits, from a decentralized interface system, output data comprising at least a portion of the cyber resilience data; and
providing, by the one or more processing circuits, the output data to a data source or distributed ledger.
1. A method, comprising:
identifying, by one or more processing circuits, one or more decentralized compute and data store interface (DCDSI) endpoints and corresponding access information;
generating, by the one or more processing circuits, an object package corresponding to the one or more DCDSI endpoints, wherein generating comprises: initiating the object package based on an identifier corresponding to at least one DCDSI endpoint type, wherein the object package is structured according to the at least one DCDSI endpoint type; and
mapping, in the object package, the corresponding access information to an access scheme corresponding to one or more formatted requests to access the one or more DCDSI endpoints, wherein the one or more formatted requests correspond with requesting protection data comprising cyber resilience data of an entity or third-party, wherein the cyber resilience data corresponds to at least one of a cybersecurity metric, incident data, compliance information, or operational data of the entity or third-party; performing, by the one or more processing circuits, a DCDSI endpoint request by: invoking the object package to execute the DCDSI endpoint request using at least one formatted request of the one or more formatted requests; and
receiving output data comprising a response to the DCDSI endpoint request by a DCDSI system, wherein the output data comprises at least a portion of the cyber resilience data; and
updating, by the one or more processing circuits, a distributed ledger or data source based on the output data.
Claims 1-20 are rejected on the ground of non-statutory double patenting as being unpatentable over claims1-20 of U.S. Patent No. US 12299162 B1. Although the claims at issue are not identical, they are not patentably distinct from each other because of similar limitations with minor obvious variations .
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 1-4, 7-13, 16-20 are rejected under 35 U.S.C. 103 as being unpatentable over MEE et al(US 20220198444 A1: IDS supplied) in view of Malden et al(US 20240012919 A1).
With regards to claim 1, 10, 19 MEE discloses, A method ([0077] The disclosure also provides a non-transitory computer-readable storage medium having stored thereon executable instructions that, as a result of being executed by a processor of a computing device or system, cause the computing device or system to at least perform one aspect or embodiment of the computer-implemented methods described herein.), comprising: identifying or determining, by one or more processing circuits, one or more endpoints (FIG 3a 314a and associated text; [0307] A computer implemented method associated with a transaction for a distributed ledger, wherein an alias is provided for a client among one or more clients associated with a payment service, the alias being specific to the client, each client being associated with a respective alias [0014] FIGS. 3a and 3b are flow diagrams depicting methods of identifying a public address associated with an alias according to a second aspect, implemented by a one or more processors of a payment service and a payment client entity, respectively.)
mapping, by the one or more processing circuits, in a data package, access information of the one or more endpoints to a structure corresponding to one or more endpoint requests to access the one or more endpoints (FIG 1 and associated text; [0080] Step 102 relates to assigning or providing an alias for a given digital wallet in a network of digital wallets. This relates to providing a mapping or correlation of aliases with the respective public addresses associated with the digital wallets, so that the aliases can be used instead of the public addresses. Such assignment may be made when a particular payment client or entity signs up to the network, for example. At this point an “alias: public address” pair may be provided for each wallet. [0120] In step 308a, the payment service associated with the alias is identified. This is based on the network identifier, i.e. nchain, in the alias. The payment service associated with this identifier, i.e. bsvalias, is identified in this step. Host discovery according to the first aspect to identify a service record may also be performed prior to this, although this is not essential for the embodiment shown in FIG. 3. For example, a mapping stored in a database or a text document based service discovery process may also be used to identify the host for bsvalias instead of the service record in the first aspect.), wherein the one or more endpoint requests correspond with requesting cyber resilience data ([0032]; Certain functions may be considered key for facilitating a cryptocurrency payment transaction associated with a distributed ledger, such as locating at least one endpoint identifier associated with the payment service, or implementing a secure communication mechanism based on public key infrastructure (PKI) etc. These functions are in most cases specified separately to the capabilities entry in the machine readable resource. Advantageously the capabilities entry enables provision of a specification, i.e. a record, of all supporting functions that can be availed. For example, details for configuring specific types of validation, additional security for specified types of transactions or networks, levels of encryption, types of PKI architectures supported, levels of addressing etc. may be provided in the capabilities object. [0112] [0113);
performing, by the one or more processing circuits using the data package, a request corresponding to at least one endpoint request of the one or more endpoint requests; (FIG 5-6 and associated text; [0138] FIGS. 5a and 5b are flow diagrams depicting methods according to the third aspect of the disclosure, for identifying a payment destination associated with an alias in a request for a transaction. The payment destination is used in constructing a transaction for a distributed ledger. FIG. 5a shows the method implemented by a one or more processors associated with the payment service, while FIG. 5b shows the method implemented by a one or more processors associated with the payment client entity. In some embodiments, obtaining the payment destination is based on, or is part of obtaining the public address associated with the alias in FIGS. 3a and 3b. In some embodiments, the payment destination endpoint identifier relates to an address that is to be encoded or included in an output script, so that a transaction may be constructed for the blockchain based on this address.); and
receiving or identifying, by the one or more processing circuits, from a decentralized interface system, output data comprising at least a portion of the cyber resilience data; (FIG 5-6 and associated text; [0112] an entry associated with at least one capability among a plurality of capabilities supported by the payment service. This may be one or more functions, such requesting entity or payer entity validation, multiple digital signatures for transactions, payee entity or payment destination approval for transactions, and/or email based payment transactions so that transactions are sent to an email address associated with an alias before posting to a distributed ledger, payer and/or payee call-back function relating to requests or responses etc. that may be supported by the payment service. [0206] The present aspect also increases the security for payment transactions made for the payee client, the digital signature of a payer has to be verified before submitting it to the blockchain, which is an added security measure. The payment service for the payee client may choose to reject signed transactions that do not pay to the keys associated with the alias in the payment request template. When rejecting requests, the payment service may choose any HTTP status code they like 401 (Unauthorsied) 204 (No Content) or 404(Not Found)); and
providing, by the one or more processing circuits, the output data to a data source or distributed ledger ([0083] Step 106 relates to updating or including in the service record created in step 104, an entry or field to indicate the payment service that is provided by the network or domain associated by the network identifier. Updating the service record in the DNS indicates that a particular network identifier, such as nchain.com provides or uses a certain payment service, for example one that is identified as “bsvpay” or “bsvalias”, for instance. This step of updating indicates to the entity performing the DNS lookup that the identified payment service, i.e. considering “bsvalias”, enables payment transactions to be made for an alias associated with the nChain domain.).
MEE does not exclusively but Malden teaches, wherein the one or more endpoint requests correspond with requesting cyber resilience data corresponding to at least one of a cybersecurity metric, incident data, compliance information, or operational data of an entity or third-partye ([0043] In FIG. 1, server computer 110 is executing supply chain incident management application 112. In an embodiment, supply chain incident management application 112 comprises program instructions that are programmed or configured to receive requests to grant an external user or non-user access to incident data managed by a group account, determine whether the external user or non-user may be granted access to the incident data, and create and store access permission information in association with the request; 0041] In some embodiments, data stored in data store 140 includes group account data 142, individual user account data 144, and incident data 146. In this context, incident data 146 may refer to data for any object type, including incidents, tasks, approvals, or others, as described in further detail herein.) It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention was made to modify MEE’s method/system/product with teaching of Malden in order to provide data security in networked data storage ( Malden [0001])
With regards to claim 2, 11, 20, MEE further discloses, determining, by the one or more processing circuits, entity data of the entity based on at least one token stored on the distributed ledger or data source ([0177] In some embodiments, in addition to including the alias of a payee entity, it may be enough if the field identified as payerHandle in the above schema is present, or associated with the request. In some embodiments, if the payer entity or digital wallet associated with the payer client does not have an alias for payment transactions, then this payerHandle may simply be associated with a public identifier or IP or Bitcoin address for the payer. Hereinafter, the payerHandle in this disclosure is described as being an alias associated with the payer client entity.); and wherein performing the request further comprises providing the entity data and the access information as input to the data package ([0120] In step 308a, the payment service associated with the alias is identified. This is based on the network identifier, i.e. nchain, in the alias. The payment service associated with this identifier, i.e. bsvalias, is identified in this step. Host discovery according to the first aspect to identify a service record may also be performed prior to this, although this is not essential for the embodiment shown in FIG. 3. For example, a mapping stored in a database or a text document based service discovery process may also be used to identify the host for bsvalias instead of the service record in the first aspect.).
With regards to claim 3, 12, MEE further discloses, wherein the access information comprises a taxonomy comprising at least one endpoint address and one or more (i) authentication credentials, (ii) request parameters, or (iii) response formats corresponding to the one or more endpoints, and wherein performing the request further comprises: providing, by the one or more processing circuits, the one or more (i) authentication credentials, (ii) request parameters, or (iii) response formats as the input to the data package based on the taxonomy ([0185] In some embodiments, the MoneyButton BSV library's implementation is nominated as the standard message digest construction and signature encoding method for signatures included in payment destination requests. The message or request to be signed may begin with Bitcoin signature scheme's traditional or known preamble (as may be documented within a BSV library's source code), and is followed by the Unicode Transformation Format-8-bit (UTF8) string concatenation of the fields payerHandle and dt, and optionally the amount and purpose fields that are discussed in the above example schema.); and invoking, by the one or more processing circuits, the object package to perform the request to the at least one endpoint address ([0170] In step 602, a payment destination request template from the machine readable resource is obtained from the machine readable resource associated with the payment service. In some embodiments, this is a temple to request the payment destination endpoint identifier discussed in FIGS. 5a and 5b. For instance, following on from the examples discussed above for the payment service bsvalias, the template may be:[0171] “paymentDestination”: http://bsvalias.example.org//name}@{domain.tld}/payment-destination).
With regards to claim 4, 13 MEE further discloses, wherein accessing the token further comprises: establishing, by the one or more processing circuits, a data communication link with the ledger, wherein the ledger comprises a blockchain network or database ([0055] The fourth aspect relates to a computer implemented method of implementing a payment service for one or more clients for transactions associated with a distributed ledger, such as the Bitcoin blockchain. In a first implementation, the method is performed by one or more processors associated with a payment service.); transmitting, by the one or more processing circuits and via the data communication link, a query to the blockchain network or database to identify the token, wherein the query comprises an identifier or address corresponding with the entity ([0030-33] In accordance with a second aspect, the disclosure relates to a computer implemented method of implementing a payment service for a one or more digital wallets for transactions using a distributed ledger, the method comprising creating a machine readable resource associated with the payment service, wherein the machine readable resource comprises an endpoint identifier for a host computing resource responsible for implementing the payment service for each digital wallet in the one or more digital wallets (or a network), where each digital wallet is associated with an alias. The machine readable resource further includes an entry associated with at least one capability among a plurality of capabilities supported by the payment service. The machine readable resource further includes instructions and/or a specification for accessing a public address or the location or one or more resources for facilitating transactions associated with the alias. The method further comprises providing the machine readable resource at a predictable or known location associated with the host computing resource for the payment service.); retrieving, by the one or more processing circuits and via the data communication link, the token from the blockchain network or database using the identifier or address ([0099] In step 204a, responsive to the request or input in step 202 a search or lookup of the global directory, for example a DNS lookup is performed based on the alias input. This is to locate the service record for the payment service in the global directory that relates to the network identifier in the alias. Thus, using the same example as discussed above for FIG. 1, this step will identify the service record for the domain nchain as shown above, since nchain in the network identifier in the alias received. This service record for nchain will then identify that bsvalias is the payment service used for nchain.); verifying, by the one or more processing circuits, an authenticity of the token ([0047]; Payment details for the transaction from the payer entity are then obtained, the payment details including at least an alias associated with the payee entity's digital wallet and an amount of cryptocurrency to be paid to the payee. A digital signature for associating the payment details with a cryptographic key for the payer entity is then obtained. An output script associated with the payment destination endpoint identifier associated with the alias is then generated for provision to the payer entity. The output script is provided for embedding in a payment transaction for the distributed ledger. [0053]; ); and extracting, by the one or more processing circuits, the entity data from the token ([0068]; a digital signature for associating the payment details with a cryptographic key pertaining to the payer entity.).
With regards to claim 7, 16 MEE further discloses, wherein generating the object package further comprises: receiving, by the one or more processing circuits, an object data structure comprising operations for communicating with and exchanging data with the one or more endpoints based on an endpoint type([0047] The third aspect of the present disclosure provides a method where the step of obtaining the public address associated with the alias in the second aspect discussed above, further include the steps of obtaining a payment destination of a payee entity associated with an alias, the payment destination for use in constructing a transaction for making a cryptocurrency payment from a payer entity to the alias. The step of constructing the transaction according to the third aspect comprises, accessing the machine readable resource based on identifying the payment service. This is followed by returning a payment destination endpoint identifier based on the one or more instructions and/or specification in the machine readable document. Payment details for the transaction from the payer entity are then obtained, the payment details including at least an alias associated with the payee entity's digital wallet and an amount of cryptocurrency to be paid to the payee. A digital signature for associating the payment details with a cryptographic key for the payer entity is then obtained. An output script associated with the payment destination endpoint identifier associated with the alias is then generated for provision to the payer entity. The output script is provided for embedding in a payment transaction for the distributed ledger.) ; and modifying, by the one or more processing circuits, a state of the object data structure to cause the object data structure to perform the endpoint request based on the access information (FIG 1 102-108 and associated text; [0127] Step 312b relates to the requesting entity determining if one or more capabilities for the requested transaction are present in the machine readable resource. This step involves checking the JSON document to identify if one or more entries relating to a common or specified supported capability will be suitable or needed for the requested transaction, similar to step 312a of FIG. 3a. ).
With regards to claim 8, 17 MEE further discloses, wherein updating the distributed ledger or data source further comprises: mapping, by the one or more processing circuits, the output data to an output information scheme corresponding to one or more outputs from accessing the one or more endpoints ([0080] Step 102 relates to assigning or providing an alias for a given digital wallet in a network of digital wallets. This relates to providing a mapping or correlation of aliases with the respective public addresses associated with the digital wallets, so that the aliases can be used instead of the public addresses. Such assignment may be made when a particular payment client or entity signs up to the network, for example. At this point an “alias: public address” pair may be provided for each wallet. The alias is unique for a particular wallet and either includes a network identifier, such as the domain name of the network, or a name that identifies that network.).
With regards to claim 9, 18 MEE further discloses, wherein the one or more endpoints comprise one or more application programming interfaces (APIs), wherein the access scheme comprises one or more rules ([0037-42] In some embodiments, in response to receiving a request from a requesting entity for a transaction associated with an alias, the method further comprises steps of identifying the payment service associated with the alias based on the network identifier. Then, based on identifying the payment service, the method includes accessing the machine readable resource from the predictable or known network location. Upon determining if one or more capabilities required for the requested transaction are present in the machine readable resource, the method includes returning an endpoint identifier of the host computing resource for the payment service, and based on this, obtaining a public address associated with the alias in accordance with one or more of the instructions and/or specification in the machine readable resource.), and further comprising: validating, by the one or more processing circuits, the access information against at least one of the one or more rules to determine compatibility with the access scheme either (i) before performance of a data retrieval corresponding to the DCDSI endpoint request or (ii) after performance of the data retrieval ([0032]; Certain functions may be considered key for facilitating a cryptocurrency payment transaction associated with a distributed ledger, such as locating at least one endpoint identifier associated with the payment service, or implementing a secure communication mechanism based on public key infrastructure (PKI) etc. These functions are in most cases specified separately to the capabilities entry in the machine readable resource. Advantageously the capabilities entry enables provision of a specification, i.e. a record, of all supporting functions that can be availed. For example, details for configuring specific types of validation, additional security for specified types of transactions or networks, levels of encryption, types of PKI architectures supported, levels of addressing etc. may be provided in the capabilities object. Accordingly, a requesting entity can discover and ensure that a required capability associated with the alias is firstly compatible with the requesting entity's resources, and secondly provided for any transactions with the alias by accessing the machine readable resource associated with the payment service of the alias).
Claims 5-6, 14-15, are rejected under 35 U.S.C. 103 as being unpatentable over MEE et al(US 20220198444 A1: IDS supplied) in view of Malden et al(US 20240012919 A1) further in view of SATAKE(US 20230129276 A1)
With regards to claim 5, 14 MEE in view of Malden but SATAKE teaches, wherein identifying the one or more endpoints and the access information further comprises: extracting, by the one or more processing circuits using a machine learning model, the access information from at least one document or content corresponding with the one or more endpoints (SATAKE [0056] Illustrative embodiments collect the training data for the user access context generator from a plurality of trusted (e.g., authorized) users. For example, illustrative embodiments limit protected resource access to trusted users when the system is initialized and running for the first time. Illustrative embodiments allow the trusted users to randomly access protected resources using various and varied user access contexts. Illustrative embodiments record the various user access contexts of the trusted users upon requesting access to the different protected resources and also record attributes corresponding to each of the requested resources. Illustrative embodiments utilize the recorded user access contexts and recorded resource attributes as training data for the machine learning model of the user access context generator.). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention was made to modify MEE in view of Malden’s method/system/product in order to providing access policies bato a database via the endpoint and REST interface ( SATAKE Abstract).
With regards to claim 6, 15 MEE in view of Malden and SATAKE discloses, detecting, by the one or more processing circuits, an update to the one or more endpoints based on monitoring the at least one document or content using the machine learning model (SATAKE [0070] At 518, resource access controller 510 records user access context of each respective user resource access request by group of trusted users 502 and the attributes of each requested resource in resource access log 512 upon access to the resources by group of trusted users 502. In this example, resource access controller 510 records in resource access log 512 “Last updated from the user access context {AtOffice, Alone}: 01/02/2021, read access for file named ‘Sales Information (Confidential).xlsx’” for Resource A and “Last updated from the user access context {IsEditor}: 01/02/1999, write access for file named ‘Test History.log” for Resource B.); modifying, by the one or more processing circuits, the access information based on the detected update (MEE FIG 1 102-108 and associated text; [0127] Step 312b relates to the requesting entity determining if one or more capabilities for the requested transaction are present in the machine readable resource. This step involves checking the JSON document to identify if one or more entries relating to a common or specified supported capability will be suitable or needed for the requested transaction, similar to step 312a of FIG. 3a.); and mapping, by the one or more processing circuits, the modified access information to the access scheme corresponding to the one or more formatted requests (MEE FIG 1 and associated text; [0080] Step 102 relates to assigning or providing an alias for a given digital wallet in a network of digital wallets. This relates to providing a mapping or correlation of aliases with the respective public addresses associated with the digital wallets, so that the aliases can be used instead of the public addresses. Such assignment may be made when a particular payment client or entity signs up to the network, for example. At this point an “alias: public address” pair may be provided for each wallet.),). Motivation would be same as stated in claim 5.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. US 20210034669 A1.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MOHAMMED WALIULLAH whose telephone number is (571)270-7987. The examiner can normally be reached 8.30 to 430 PM.
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, Yin-Chen Shaw can be reached on 1-571-272-8878. 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.
/MOHAMMED WALIULLAH/Primary Examiner, Art Unit 2498
Prosecution Insights