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 .
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-2, 5-6, 9-10, 11-12,15-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 McLaughlin et al(US 20210034669 A1).
With regards to claim 1, 11, 20 MEE discloses,1. A method for configuring an integration environment, the method comprising:
receiving, by one or more processing circuits, a request corresponding with at least one decentralized compute and data store interface (DCDSI) endpoint of an integration ([0098] In step 202a of FIG. 2a, the payment service receives a request from a requesting entity for a transaction associated with the alias. This request may be in the form of an input from an interface of a computing device of the requesting entity, i.e. the digital wallet that may be installed.), wherein the request comprises at least a public identifier and a private identifier (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 [0101] In step 208a, based on the location, i.e. target: port pair, of the host obtained in step 206a, a public address of the digital wallet associated with the alias may then be determined.[0009]; Identifying and then accessing the relevant data from the blockchain is based on the public address (linked to the private keys) of the entities involved in the transaction. );
authenticating, by the one or more processing circuits, access to the integration using at least one of the public identifier or the private identifier ([0262] 15. The method as set out in any one of clauses 13 or 14, wherein each client is associated with a digital wallet pertaining to a user or entity registered for the payment service in the network, wherein each digital wallet is a cryptocurrency wallet associated with a public key and a private key of an asymmetric cryptography key pair for transactions on the distributed ledger, and wherein the step of obtaining the public address includes obtaining the public key of the digital wallet associated with the alias.);
determining, by the one or more processing circuits, an access scheme of the at least one DCDSI endpoint based at least on the request, wherein the access scheme corresponds with one or more formatted requests for the at least one DCDSI endpoint (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.), and wherein at least one formatted request of the one or more formatted requests corresponds with establishing a communication channel with the integration via the at least one DCDSI endpoint ([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);
generating, by the one or more processing circuits, one or more configurations of an object package corresponding with the at least one formatted request, ([0037-0045] In some embodiments, the machine readable resource is generated using a Java Script Object Notation (JSON) format.[0108];); and
invoking, by the one or more processing circuits, the object package to establish the communication channel with the integration by executing a DCDSI endpoint request to the at least one DCDSI endpoint using the at least one formatted request (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.). 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 base embodiment(FIG 1) with teaching of other embodiments in order to implementing a payment service for one or more clients for transactions associated with a distributed ledger, such as the Bitcoin blockchain ( MEE Abstract)
MEE does not exclusively but Mclaughlin teaches, wherein the object package is structured based on at least the access scheme (FIG 1-2 and associated text; [0035] Endpoints can be declaratively specified in the style of REST- based standards (representational state transfer) and/or XML-RPC-based standards (remote procedure call protocol using XML to encode calls and HTTP as a transport mechanism), which provides immediate access to a wide variety of extant software tools. [0036] In various embodiments, an endpoint specification includes an endpoint "target," expressed as an identity or a noun, and any of a list of parametric verbs specifying "actions" to be taken in the context of the target. [0037] Each action is associated with a "parametric query," whose arguments are either part of the context of the service request, part of any data available in a "session" context, part of any data available within a transaction's context, and any "global" data available within the server in which the query runs.[0048-49];[0022]; ) 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 in order to providing access to a database via the endpoint and REST interface( McLaughlin Abstract)
With regards to claim 2, 12, MEE further discloses, wherein the one or more configurations comprise one or more access roles or access permissions of the integration ([0020]; wherein the host computing resource is configured to facilitate identification of the client associated with the alias, responsive to receipt of a request pertaining to a transaction related to the alias.), and wherein establishing the communication channel comprises: registering, by the one or more processing circuits, the public identifier with the at least one DCDSI endpoint ([0026] Advantageously, this enables discovery of a host responsible for providing a payment service to facilitate a payment transaction to a payee entity, based on just the alias of the payee entity, thereby significantly simplifying payment addressing for payment transactions for a digital ledger. Once the host has been located, a public address associated with the client or digital wallet of the payee entity can be determined since the digital wallet is associated with the network or network identifier, and thereby associated with the payment service. The term public address referred herein relates to an identity or address for a digital wallet or client, and in some embodiments, pertaining to one or more (future) transactions for the distributed ledger. In some embodiments, the public address may be the payment address or destination address for the client or digital wallet. In other embodiments, the public address may be used to derive the payment or destination address. This public address may be the same or may be different for each transaction that is associated with the digital wallet.); and configuring, by the one or more processing circuits, the one or more access roles or access permissions based on the access scheme for the at least one DCDSI endpoint ([0022]; The location of the host computing resource may be the location of a server that is responsible for the provision of the payment service for the network. For example this may be an endpoint universal resource identifier (URI) and may include the universal resource location (URL) of a web server, from where the payment service may be accessed by other entities. For example, the other entities may be digital wallets that may or may not be part of the network associated with the network identifier, one or more payment server or client entities, or a payment application ; see also [0032];).
With regards to claim 5, 15 MEE further discloses, wherein determining the access scheme comprises: transmitting, by the one or more processing circuits, a plurality of self-executing requests to the at least one DCDSI endpoint ([0006] Presently, in order to facilitate a BSV cryptocurrency payment between users, i.e. from Alice and Bob, Alice would need to have a digital wallet associated with her (private and public) cryptographic keys and would need to know Bob's public address for sending cryptocurrencies, i.e. Bob's digital wallet address. The public addresses associated with an entity, herein a digital wallet, as are usually automatically generated by an address generation program.), wherein the plurality of self-executing requests comprise instructions configured to cause the at least one DCDSI endpoint to retrieve data corresponding with the access scheme (FIG 1 102 and associated text; [0006]; These public addresses are a string of digits in a specific format that is recognised by the cryptocurrency network and is used for transactions. For instance, these may be the Bitcoin addresses for BSV based cryptocurrency networks. This can be referred to as the public key or hash of the public key of the asymmetric private/key pair associated with an entity. Public addresses can be shared publicly so that other users know where to send payments in cryptocurrency to. However, public addresses which are recognised and used by the BSV wallet ecosystem or other cryptocurrency wallets are in formats such as:); and identifying or generating, by the one or more processing circuits, the access scheme based at least on a response to the plurality of self-executing requests from the at least one DCDSI endpoint, wherein the response comprises the data corresponding with the access scheme (FIG 1 104 and associated text; [0068]; In some embodiments, the HTTPS POST request of the fourth aspect is similar to the HTTPS POST request flow for the payment destination in in FIG. 6, but in this case the payer entity does not have to access the machine readable document as the output scripts are included in the payment request template from the payment service. In some embodiments the digital signature is verified based on the HTTPS GET request flow as seen in relation to FIG. 4 to resolve the public key of the payer entity, if the payer entity is associated with a payment service. The method then includes submitting the completed payment transaction to the distributed ledger.).
With regards to claim 6, 16 MEE further discloses, validating, by the one or more processing circuits, the one or more configurations based on simulating one or more access requests on the at least one DCDSI endpoint to invoke the object package ([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), wherein invoking the object package to perform validation comprises determining at least one response to the one or more simulated access requests corresponds with an expected access outcome based on the one or more configurations ([0004] In order for a transaction to be written to the blockchain, it must be “validated”. Network nodes (miners) perform work to ensure that each transaction is valid, with invalid transactions rejected from the network. Software clients installed on the nodes perform this validation work on an unspent transaction (UTXO) by executing its locking and unlocking scripts. If execution of the locking and unlocking scripts evaluate to TRUE, the transaction is valid, and the transaction is written to the blockchain. Thus, in order for a transaction to be written to the blockchain, it must be i) validated by the first node that receives the transaction—if the transaction is validated, the node relays it to the other nodes in the network; and ii) added to a new block built by a miner; and iii) mined, i.e. added to the public ledger of past transaction).
With regards to claim 9, MEE further discloses, wherein invoking the object package comprises: retrieving, by the one or more processing circuits, the one or more configurations of the object package ([0108] In some embodiments, JSON (JavaScript Object Notation) which is a lightweight data-interchange format, is used to generate the machine readable resource. JSON is a text format that is completely language independent but uses conventions that are familiar to programmers of the C-family of languages, including C, C++, C#, Java, JavaScript, Perl, Python, and many others. These properties make JSON an ideal data-interchange language. Further JSON is built on two structures, a collection of name/value pairs and an ordered list of values. In most languages, this is realised as an array, vector, list, or sequence. As these are universal data structures, virtually all modern programming languages support them in one form or another. Thus, using JSON for the machine readable resource is preferable, as it provides a data format that is interchangeable with other programming languages that may also be based on these same structures.); populating, by the one or more processing circuits, one or more fields or parameters of the at least one formatted request based at least on the access scheme and the one or more configurations([0116] Step 304a relates to storing the machine readable resource at a predictable or known location associated with the payment service. For example, a payment service operator or processor for the payment service “bsvalias”, following creation of a JSON formatted text document as described above in step 302a may provide the document at the following location:), wherein the one or more fields or parameters correspond with one or more data structures or instructions configured to cause the at least one DCDSI endpoint to perform one or more cyber resilience operations ([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); and transmitting, by the one or more processing circuits, the at least one formatted request to the at least one DCDSI endpoint (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.)).
With regards to claim 10, MEE further discloses, wherein authenticating access to the integration comprises: determining, by the one or more processing circuits, the public identifier is stored or maintained in a registry of authorized public identifiers accessible to the integration ([0262] 15. The method as set out in any one of clauses 13 or 14, wherein each client is associated with a digital wallet pertaining to a user or entity registered for the payment service in the network, wherein each digital wallet is a cryptocurrency wallet associated with a public key and a private key of an asymmetric cryptography key pair for transactions on the distributed ledger, and wherein the step of obtaining the public address includes obtaining the public key of the digital wallet associated with the alias.); comparing, by the one or more processing circuits, the private identifier to a cryptographically hashed value or token stored in association with the public identifier ([0101] In step 208a, based on the location, i.e. target: port pair, of the host obtained in step 206a, a public address of the digital wallet associated with the alias may then be determined.[0009]; Identifying and then accessing the relevant data from the blockchain is based on the public address (linked to the private keys) of the entities involved in the transaction.); and authenticating, by the one or more processing circuits, the access to the integration based on matching the private identifier and the cryptographically hashed value or token ([0143] In step 510a the digital signature may be verified, so that the identity of the payer entity can be authenticated. This may be performed using one or more known techniques. In some embodiments, assuming that ECDSA keys are used, the public key of the payer entity, for instance obtained using the PKI sequence in FIG. 4, can be used to verify the identity of the signing entity (the payer entity). [0137] If the request is based on an alias that is not valid, i.e. one that is not associated with the payment service and/or a public key, then the return message will indicate that an error has occur or that the requested resource is not found or is unavailable or unauthorised.).
Allowable Subject Matter
Claims 3-4, 7-8, 13-14, 17-19 are objected to as being dependent upon a rejected base claim but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
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