Eligibility of work in SR&ED projects containing software development
Ubiquitous presence of software in modern goods and services is undisputable. Software development seems to play a part in the creation of new or improved products and services in almost every sector. Naturally, a great percentage of the claims for scientific research and experimental development (SR&ED) have software development in them. This webinar is an effort to illustrate the concepts of SR&ED when applied to work involving software development.
First, we will provide a brief recap on SR&ED, eligibility policy, and technology definition. We will then apply it to work containing software development, and illustrate it through examples. In other words we will:
- examine the eligibility of work that incorporate software development, for SR&ED, through practical examples,
- provide a common understanding of SR&ED in the context of software development.
Considering the time constraints, we hope that everybody understands that it will not be possible for us to focus on each and every aspect of this. Also, this presentation will focus on the technical aspects associated with the eligibility of work.
In this webinar, we will go over the important aspects of the definition of SR&ED and the methodology used in determining the eligibility of work.
Broadly examine where we encounter software development in SR&ED claims.
Illustrate the concept of technology as it applies to software.
Look at some areas of advancement to illustrate that the potential for advancement exists in many areas.
Examine key SR&ED concepts in the 5 Question methodology through software development examples.
For work to qualify for tax incentives, the work must meet the legislative definition of scientific research and experimental development. Therefore, whenever we are referring to "eligibility of work" or "eligible work", we are referring to the work that meets the legislative definition of SR&ED. SR&ED is defined in the subsection 248(1) of the Income Tax Act.
The first part of the definition essentially tells us how SR&ED work is conducted, that is, the work must be a systematic investigation or search carried out by means of experiment or analysis in a field of science or technology.
The second part of the definition identifies why the work is conducted, that is, the work must be undertaken either:
- for the advancement of scientific knowledge (identified as (a)basic or (b)applied research depending on whether a specific application is in mind or not) or
- for (the purpose of) achieving technological advancement (identified as (c) experimental development).
The two-step methodology is used to determine if and to what extent work meets the definition of SR&ED:
Step 1 – Determine if there is SR&ED, and
Step 2 – Determine the extent of eligible work (only if there is SR&ED).
The focus of this webinar is the eligibility of work containing software development and we will limit the scope to Step 1.
To determine if there is SR&ED, we use the five-questions method as outlined in the eligibility policy.
The method to establish if there is SR&ED involves answering five questions.
- Was there a scientific or a technological uncertainty?
- Did the effort involve formulating hypotheses specifically aimed at reducing or eliminating that uncertainty?
- Was the overall approach adopted consistent with a systematic investigation or search, including formulating and testing the hypotheses by experiment or analysis?
- Was the overall approach for the purpose of achieving a scientific or a technological advancement?
- Was a record of the hypotheses tested and the results kept as the work progressed?
Remember: It is determined that there is SR&ED if the answer to all five questions is "yes".
Let us now look at three scenarios where we encounter software development projects.
Here are three examples for the first scenario where the software itself is the new or improved product, process, or device.
Voice codec software like G 729 codec is a software product containing a particular implementation of a compression algorithm for voice data.
Web information system and document management tools are software products that allow document management, storage, and publishing on the web.
Protein structure prediction software for predicting three-dimensional structure model of protein molecules from amino acid sequences is a software product.
The second scenario is where new or improved product, process, or device is a combination of hardware and software. Let’s look at two examples.
Electric drive controllers can be a hardware product with embedded software incorporating both power electronics and microprocessors to exercise dynamic control over speed, torque, and efficiency.
Bank cheque reading systems based on convolutional Neural Network software can consist of mechanical and electrical hardware to automatically scan and process cheques.
The third scenario is where software development is necessary for a project but the developed software is not a part of the product, process, or device. We will look at 2 such examples.
Example 1: The development of code in Hardware Description Language (HDL) for Application Specific Integrated Circuit (ASIC) using tools such as Verilog/VHDL simulators and HDL Synthesis tools.
Example 2: Software development necessary solely for testing or conducting experiments using packet sniffing tools with scripting capability.
As mentioned in an earlier slide, Experimental Development is undertaken for the purpose of achieving technological advancement.
So, what is technology?
Technology is not a physical entity.
Technology is the practical application of scientific knowledge and principles.
It is the knowledge of how scientifically determined facts and principles are embodied in the material, device, product, or process.
As technology evolves, the practical applications of scientific knowledge and principles as well as the technological knowledge associated with the products, processes, or devices become the scientifically determined facts and principles for further development.
Let’s look at some examples to illustrate this.
A microcontroller or microprocessor can run machine code without an operating system and any user developed software can run directly on it.
In contrast, in an Operating System, user developed software runs within a managed environment.
The kernel has process management, memory management, and input/output (I/O) management to govern the environment.
Within process management, a scheduler manages tasks and processes using complex data structures working in conjunction with other embodiments. As we can see, within a modern Operating System, kernel and other embodiments not mentioned in the slide make up the scientifically determined facts and principles. Similarly for the kernel, it is the process management, memory management, I/O management and others. As we go down further, the scheduler has Lists, Queues, etc.
Even when we use a microcontroller without an Operating System, the tools used to generate the machine code can come from a tool-set.
For example, a well known open source electronic platform provides a tool which uses the principles of programming language to enable writing in a higher level language, uses the principles of compiler that turns the code into object files (machine readable instructions), and a linker to combine the object files with libraries.
Principles of programming languages, compiler, linker, and Graphical User Interface are some of the scientifically determined facts and principles within the tool-set.
Similar evolution can be seen in technologies associated with Web systems, Information systems, micro-controller based systems, relational databases, No-Structured Query Language (SQL) databases, distributed storage and retrieval etc.
We looked at the definition of technology through software examples.
New products/services are being built using or combining various technologies for creating complex applications. This is driving relentless progress.
The trend in software development has shifted in the direction of shared services such as Software as a Service, Platform as a Service and Infrastructure as a Service.
We see this manifest as Cloud computing which is made possible by tremendous advancements in hardware and software technologies.
From software perspective, Cloud services became possible through advancement in networking and distributed infrastructure and computing.
All these developments make use of various advancements in software technology stack.
This is an illustration of how various advancements provide a platform for modern big data applications.
As you all know, different companies compete in different areas of technology. For example, a company working on scalable distributed computing and processing deals with different technologies than a company working on databases or content delivery network. These companies have the potential of advancing technology in their respective areas.
Companies produce various products and services using technology. SR&ED looks at the advancement in technology necessary to deliver the new or improved products and services. Therefore it is important to distinguish between technology and product.
Often the name of the product, process, or device is also used to identify the technology.
The distinction is:
- Product, process, or device conveys feature, functionality, capability, etc.
- Technology is about the knowledge of how the constituents embodied within the product, process or device, function to deliver the feature, functionality, capability, etc.
For example: Web information system publishing tools that also serve as document management and storage systems come with features, interfaces, application program interfaces (APIs) and tool-sets to build information systems.
Understanding the capabilities and limitations of such systems for building an information system, use of their API/interfaces to develop an information system, or information about their features and functionality are about a product.
On the other hand, knowledge of the internal workings of such systems and how inter-relationships produce, influence, and impact the features, interfaces, APIs, tool-sets etc., are related to the technology.
Now let us start looking at the concepts associated with the 5 questions in the eligibility policy, starting with technological uncertainty relating to Question 1. This is covered through slides 16 to 33.
Scientific or technological uncertainty means whether a given result or objective can be achieved or how to achieve it, is not known or determined on the basis of generally available scientific or technological knowledge or experience.
Here, scientific or technological knowledge base refers to the existing level of technology and scientific knowledge, and consists of the knowledge of the resources within the company and sources available publicly.
The current state of technology may be insufficient to resolve a problem. Therefore it is important to identify the shortcomings or limitations of technology that prevents the new or improved feature, functionality, capability from being developed.
It is important to establish the technological knowledge base to identify a technological uncertainty.
Let us look at an example to illustrate the kind of information useful in establishing the technological knowledge base.
As an example, we can think of a telecom software company developing Automatic Call Distributors (ACD) for Voice over Internet Protocol (VoIP) based voice telephony, wants to prevent failures in Session Initiation Protocol (or SIP) calls due to hardware, software, system, or network failures.
Peer to peer connections through data network are susceptible to such failures resulting in session disruptions.
For voice sessions over data, this has the undesirable effect of loss of on-going phone calls and call setup in progress.
This company asserts that the objective of call continuity (continuing phone calls without re-initiating them), cannot be achieved based on the technological knowledge base.
The information used by the company in coming to such a conclusion can help in establishing the technological knowledge base.
- Starting with identifying the technology or technologies involved (such as session initiation protocol, session description protocol (SDP), real-time transport protocol (RTP) and their interactions);
- identifying what is available in the technological knowledge base with regard to peer to peer calling, failure modes, call set-up, call progress, and call tear-down;
- describing any proprietary technology involved;
- identifying any patents or technical information associated with how call failures are handled using the current state of technology;
- providing the technological experience of the company in the technology areas such as VoIP, Information theory, Voice telephony, Network protocol knowledge of Transmission Control Protocol (TCP)/User-Datagram Protocol (UDP)/SIP/SDP/RTP, etc.;
- identifying where the current state of technology is insufficient; and
- having this research documented when it was done in order to establish the technological knowledge base at that specific point in time.
Establishing the technological knowledge base properly before the assertion of a technological uncertainty will avoid re-inventing the wheel.
In the previous slides, we provided a definition for technological knowledge base, and through an example illustrated the kind of relevant information helpful in establishing the technological knowledge base.
It is important to keep in mind that technological knowledge base can be different for different companies in different technology areas.
This chart illustrates that the scientific or technological knowledge base is determined for each company on a case by case basis.
At a minimum, the scientific or technological knowledge base lies at the level of the public domain. As already mentioned, the company is expected to have information that is common knowledge at the time the work is performed. This is indicated by the scientific or technological knowledge base of company A. Comparing this against the knowledge base of company B, company B does not have all of the knowledge or expertise that is available. Any effort it undertakes to acquire this knowledge or expertise is simply learning. It is an effort to bring itself “up-to-speed” and does not involve SR&ED. In the case of Company C, their technological knowledge base is above the public domain and includes their proprietary knowledge and know-how.
As you remember from slide 16, we discussed technological uncertainty and the importance of identifying the shortcomings or limitations of technology. Next, we will be looking at limitation of technology through an example.
Here are some background information in preparation for the example:
As we are aware, access to software applications is based on confirming the identity of the user. Software applications can rely on other identity providers and trust the ID given by these providers. This is very similar to how organizations like banks rely on government issued drivers license for identification.
When there are many applications, it is convenient to be able to use the same ID for accessing them. It is even better if the process of verification for access control is performed in the background through pre-defined security policies. This type of access to software applications is referred to as single sign-on. The security of communications to request, generate, and provide ID are critical to the integrity of single sign-on.
The illustration shows one such security trust service model defined by a consortium of companies. A user requiring access to an application obtains security token from an ID provider that is trusted by the relying applications. These security tokens contain codified claims to protect and authorize requests. The claims are assertions about the user.
Web Services-Federation referred to as WS-Federation is an evolution of this model. It addresses the needs of web applications with richer trust relationships and advanced federation of services.
Now, let us look at limitation of technology through an example related to single sign-on
In 2013, a leading software company XYZ offered Cloud based access to its productivity software suite and related services through single email login authentication.
Its single sign-on (SSO) login capability was constructed on claims based user identity using its Cloud based directory and identity management service.
At that time, there were two approaches generally available in the technological knowledge base to implement single login authentication for applications offered through the Cloud services of the XYZ software company. They were as follows:
- The company offered a proprietary tool to synchronize the essential information from an organization’s internal directory service to its Cloud based directory and identity management software. This will provide local users of the organization, access to the applications hosted in the Cloud from both inside and outside the office.
- Setting up a Federation Service: The company also offered a Federation Service software for claims based access control authorization which allowed single sign-on for multiple security realms (domains). It functioned as a Security Token Service relying on individual domain controllers and performed authentication and provided security tokens for WS-Federation. This Federation Software could be used with its Cloud-based directory service for single sign-on through trust relationship.
We will walk through aspects of the two approaches, starting with Approach 2 which is the true single sign-on and which uses the Federation Service software.
Here we have a company intranet. It is setup with the Federation Service software using a Federation server and a Proxy server in the de-militarized zone for external access. The company’s Directory Service contains user object information and provides the identity information for the Federation Service.
We also have an App within the Productivity Suite in the Cloud.
The user connects to the productivity suite from the office. The same user may also want to connect to it from home using internet.
The user will be re-directed to the App.
The User will connect to the App.
Since the App trusts the Federation Service to provide Identity and Access management, the user is then re-directed to the Federation Server.
The user obtains the security token from the Federation server, if connected from the office, or its proxy, if connected from outside the office. This is the underlying process for acquiring security tokens in Approach 2.
Approach 1 is where the XYZ Cloud provides Security Token Service through its Access Control Service and its Directory service. The Cloud’s Directory service is kept synchronized to the company Directory Service using the proprietary copying tool provided by the company XYZ.
Both these approaches discussed in the previous slide, impose restriction on usernames through namespace hierarchies based on domain segregation. Additionally,
- approach 1 is not a true single sign-on, rather a way to allow internal users to access from outside, while
- approach 2 is a single sign-on but requires a federation server and proxy server for every domain controller. It also uses domain user accounts for login
As an example, a company project objective was to develop a single sign-on solution using the XYZ Cloud’s identity and access control without having username restrictions or requiring the Federation Service for identity management.
Now let us look at what is the limitation of technology in this example.
The federated single sign-on option available in the XYZ Cloud was using WS-Federation protocol.
The Cloud’s identity management trusted the Federation Service to provide the security tokens.
The technological knowledge base, including understanding of how the XYZ Cloud’s identity management worked, was insufficient for the company to develop a solution to overcome the restrictions imposed by approach 2.
At this stage, this is a limitation of the current state of technology.
Work can be undertaken to advance the knowledge towards the development of this solution that will enable single sign-on.
We will now look at a few examples to illustrate common misconceptions about technological uncertainty. The first example is to emphasize that absence of a capability does not equate to a technological uncertainty.
A company wants to build a new version of their client server mobile application. The older version of the application worked in conjunction with a well known Enterprise Server that offered server side Push. The new version of the application was required to work in setups where the Enterprise server could not be used.
In client server applications, the server responds to client requests. With a server side Push service, client applications can receive information from their servers even if they did not initiate a request.
The company cannot claim the lack of availability of the Push capability from the Enterprise server as a technological uncertainty for its work to build some form of a Push service. The company has to identify a limitation of technology that is preventing the development of its own Push service.
The second example is to emphasize importance of differentiating project objective and technological uncertainty.
A state of the art Natural Language Processing based software processes English language sentences at a rate of N words per second with an accuracy of 75% while interpreting the meaning/intent in social media conversations.
The company seeks to improve the software to 1.3*N words per second at an accuracy rate of 85%. This conveys a project objective without conveying a limitation of technology that prevents the company from achieving this objective.
Stating that there was uncertainty in whether or not the project objective can be achieved does not convey the limitation of current state of technology.
Performance targets, measure of efficiency, scaling requirements, measure of redundancy, and reliability are indicators of a product, process, device or material.
One of the reasons why certain value of a metric is unachievable may be due to existence of a technological uncertainty. However, wanting to achieve it is a functional objective, and an attempt to achieve it does not necessarily mean an attempt to achieve technological advancement by eliminating a technological uncertainty.
The third example is to emphasize importance of addressing the limitation of technology and not circumventing it.
During new or improved product development, an encountered issue can be suspected as being due to a limitation of the technology.
A company can choose to develop a solution by circumventing or avoiding the issue by using alternatives.
In such a scenario, the identified issue cannot be considered as the technological uncertainty.
Let us look at an example to illustrate this. A company has a large development group for developing third party applications for a mobile operating system. While developing mobile apps using a particular Software Development Kit (SDK), the company found that apps would fail randomly while handling large data at a fast rate.
Preliminary investigation and analysis led to the suspicion that the failure might be due to either:
- issues in virtual memory management in the SDK library, or
- a poorly built library that is unreliable.
After due consideration, the company chose not to address the SDK issue and instead decided to build their own SDK.
Since the issues of the existing SDK are not directly related to the development of the new SDK, they cannot be cited as a limitation of technology for the development of the new SDK.
It is important to identify if a limitation of technology is preventing the development of the new SDK.
We looked at an example relating to the limitation of technology. We also looked at a few examples to address some common misconceptions about technological uncertainty.
Let us look at some important characteristics about technological uncertainty.
Technological uncertainty conveys the idea that there is a problem or barrier that is technological in nature and that cannot be resolved using the knowledge and information available in the technological knowledge base.
It identifies the point where the nature of work shifts from using the technological knowledge base, to finding a solution by addressing the limitation of technology.
Confirmation that work was undertaken to reduce or eliminate a technological uncertainty is obtained through the details of the work. This will also rule out the cases where,
- the work undertaken circumvented the limitation or
- the outcome of the work undertaken is within the technological knowledge base.
Once a technological uncertainty is identified, the techniques used for systematic investigation or search can be techniques that are within the technological knowledge base.
Let us illustrate the last point with the example of experimentations that require the monitoring of data traffic in networks through packet capture using packet sniffing and analysis tools.
Even though the technique of capturing and monitoring data traffic through packet sniffing and packet analysis may be well known and are considered to be in the technological knowledge base, they are essential for experimentations where the results of the experiments are derived from the information in the packets.
After having discussed technological uncertainty, we will illustrate the concept of hypothesis which is directly relevant to answering Question 2.
Appropriate hypothesis can be formulated for further investigation after identifying what is lacking in the scientific or technological knowledge base.
So, what is hypothesis?
Hypothesis is an idea consistent with known facts.
For example, internet data transmission speed can exceed the speed of light is not consistent with known facts.
Hypothesis is a supposition or explanation on the basis of limited evidence which serves as the starting point for further investigation.
Example 1: While going through technology stack selection to decide between two real-time Operating System options, a supposition that real-time Operating System ‘A’ will offer better interrupt management than real-time Operating System ‘B’, has no linkage to anything lacking in the scientific or technological knowledge base. Therefore it is not a hypothesis for SR&ED.
Example 2: Continuing on the previous example on limitation of technology, a hypothesis can be that specific information from the Directory Service objects are used in the composition of claims for the Cloud service security tokens within WS-Federation. This on the other hand, is a hypothesis for SR&ED.
Formulation of proper hypotheses is essential for planned approach to SR&ED.
We will now illustrate the concept of Systematic investigation or search relating to Question 3. This is covered through slides 35 to 46.
With the formulation of the initial hypothesis, the investigation or search continues through experiment or analysis to address the limitation of the current state of technology.
The details of the work establishes if a systematic investigation or search (SIS) was carried out for the purpose of eliminating or reducing the technological uncertainty.
The work undertaken for developing new or improved product, process, or device can lead to different conclusions. We will illustrate this with three scenarios using examples. Note that the examples for these scenarios will also be used to illustrate concepts later in this presentation.
In scenario 1:The work undertaken confirms knowledge that is already in the technological knowledge base and determines the suitability of alternate solutions from within the technological knowledge base.
In scenario 2: While building an innovative application, encountered issues were initially suspected as a limitation of technology but the work undertaken establishes that the solution is from the technological knowledge base.
Finally in scenario 3: The work was undertaken to advance the understanding of the current state of technology beyond the technological knowledge base, reducing or eliminating a technological uncertainty.
Now we will look at the details of the example for scenario 1.
A company is building an online application that will allow users to query a very large database of information on products and pricing.The application utilizes user location to display products sorted based on proximity.The system requirements were set by search completion time and the ability to perform live updates to the database in a timely manner.
The following work was undertaken:
An initial system was built with a modern Relational Database Management System (RDBMS). The search performance did not meet the requirement of search time and the live updates were taking too long. The time consumed by the individual processes of the work-flow was measured starting from user-input to displaying final result. This identified computations that were taking too long.
Identical repetitive computations were replaced with look-up tables and cached database tables to reduce search time. The cache memory was not sufficient as there were too many large tables. The large tables were necessary to avoid complex queries with dependence on multiple tables. Changes were made and it did not provide consistent performance improvement. The overall search time performance did not improve to the desired level.
An alternate solution was built using a search platform with advanced text search capabilities. The search performance time turned out to be well within requirements but the database updates did not meet the requirements.This was investigated and changes were made to the configuration of the search platform that improved update metrics.
Now, what conclusions can we draw from the work done by the company?
By choosing a search platform meant for text searches instead of using a relational database for text searches, the search performance criteria was met. Also, the search platform needed to be configured appropriately to meet the database update requirement of the application. Both the use of text based search platform for text searches and configuration of the platform for optimized performance of their application are from within the technological knowledge base.
Now we will look at the example for scenario 2 presented earlier.
Here is a summary of the project objective and the development work.
An app developer for a popular mobile phone operating system was asked to develop a unique secure file transfer application that uses Wi-Fi to send and receive many pre-scheduled files to and from a central server.
The user of the app is not constrained to stay connected to a Wi-Fi for the completion of the file transfers.
An application was created with a capability to queue and schedule file transfers based on a standard secure file transfer protocol.
Whenever the phone had Wi-Fi connectivity, the scheduler within the app would initiate and continue pre-scheduled data transfers.
The application encountered transfer failures whenever the user moved out of a Wi-Fi range, requiring re-transfer or use of expensive wireless data.
The testing of the issue revealed that the failures were more common when the file size was over a certain limit.
The files were divided into smaller chunks, transmitted one chunk at a time, keeping track of the chunks transmitted.
This solved the initial issue but created other issues like the device consuming too much resource and time in preparing the files thereby impacting scheduling.
To overcome this, the developers decided to transmit fixed size data and keep track of the pointer to the end location of the last transmission to eliminate preparation time.
Now, what conclusions can we draw from the work undertaken in this example?
The app development required transmitting small size data, keeping track of the files through pointers, and having a process to schedule/manage files, and data within a file. The knowledge to accomplish this was within the technological knowledge base. Even though the app may be unique, there was no limitation of technology that prevented the development of it.
The work, though conducted systematically, was not towards reducing or eliminating a technological uncertainty. Therefore it is not considered a Systematic Investigation or Search for the purpose of resolving a technological uncertainty.
This example for scenario 3 is a continuation of the previous example under “Limitation of technology” and describes the work that was undertaken towards advancing the understanding of how XYZ Cloud uses information in the Directory Service object for single sign-on identify management.
Let us look at the work undertaken.
A setup consisting of XYZ Cloud’s Access Control Service using the Cloud’s Directory Service instance as the ID provider for a relying application was created. A packet sniffing tool was setup to capture and analyze the user browser network traffic and log during login attempts4. The Cloud’s Directory Service was populated with user objects from a local Directory Service using the proprietary synchronization tool as in approach.
The visibility of claims within the WS-Federation was confirmed during login attempts. The next effort was to understand the relationships between claim attributes and Directory Service user objects. The observations and analysis of the claim attributes of the captured information within security tokens, allowed the mapping and expression of the correlation between the Directory Service user object attributes and the object attributes used within the Cloud’s identity management entities.
The next activities were towards validating the relationships, determining whether Security Token Service provided by the Federation Service can be substituted, and finding out what may be necessary to mimic any Federation Service specific behavior.
To accomplish this, an open source security token server was setup. A trust association between the server and XYZ Cloud identity management was established. The signing algorithm and signing certificates were aligned between the two. These steps were necessary to configure the use of the security token server as the identity provider for the Cloud Service. Based on the developed relationships, the server source code was modified to create new claim types structured using Directory Service user object attributes.
By undertaking several tests, it was possible to understand where and how the Directory Service object attributes were used in the claims for the Cloud Service. The results enabled the construction of a single sign-on for XYZ Cloud Service without Federation Service where it was possible to use attributes and unique-ids that did not belong to the Directory Service. This also led to the development of user stores without the Directory Service.
Again, what conclusions can we draw from the work undertaken in this example?
From the work described, we can conclude that the Information on the work undertaken is at sufficient level of detail that both a claimant and a reviewer from the Canada Revenue Agency (CRA) can agree on the statements of facts, see the characteristics of the work undertaken, and identify new knowledge. With reasonable effort, the reviewer (and the claimant) can determine and agree if this is over and above the technological knowledge base.
Here are some additional points on systematic investigation or search.
If the work generates or confirms what is within the technological knowledge base, even though the work was undertaken systematically, it will not be considered as SIS for reducing or eliminating technological uncertainty.
Work resulting in generation of new knowledge that explains the reasons of failure of possible solutions to achieve a technological objective is considered a technological advancement provided it is not available in the existing technological knowledge base.
Now we will examine the concept of technological advancement relating to Question 4. This is covered through slides 47 to 51. As we already know, Experimental Development is undertaken for the purpose of achieving technological advancement for the purpose of creating new or improved product, process, device, or material.
Scientific or technological advancement is the generation of information or discovery of knowledge that advances the understanding of scientific relations or technology.
Key milestones in the pursuit of technological advancement are:
- identifying that there is a limitation in the current state of technology,
- undertaking work to address the limitation, and
- work leading to an understanding of the principles, techniques, and concepts beyond the existing technological knowledge base
Technological advancement is the new knowledge that is applicable beyond the current project.
Technological advancements in software development projects can involve:
- New or improved techniques and methods in computing to store, search, process, and manage vast collection of data (big data). Typically undertaken in Universities and large research labs.
- Advancements necessary in support of software technology stack or tools.
- Advancements necessary for new or improved infrastructures like internet driven Cloud and distributed computing.
- Advancements necessary to support scaling, reliability, and availability of software based systems.
- Advancements in other technology areas like vision and medical imaging, video transmission, telecommunication (voice), automation, controls, etc.
We will re-look at the three earlier examples discussed under the Systematic Investigation or Search to illustrate what is and what is not technological advancement. If you recall the example from scenario 1 where the company set out to build an online application that queries a very large database of information on products and pricing. Initially they built it using a relational Database and it did not meet their requirements. They then built the application using a text based search platform. Let us say that the following is stated as the technological advancement.
Built an online application that displays search information of available products and pricing based on proximity to the user as well as performing tasks within time requirements.
Do you think this statement represents a technological advancement?
The Answer is, no. Why?
Because it describes functionality and capability of an application and does not convey the technological advancement required to build the capability or functionality.
Let us now look at the example from scenario 2. This is the example where an app developer for a popular mobile phone operating system was asked to develop an unique secure file transfer application that uses Wi-Fi to send and receive many pre-scheduled files to and from a central server.
Let us say that the creation of this secure file transfer application with its unique functionality is stated as the technological advancement for the project.
Do you think this statement represents a technological advancement?
The Answer is, no. Why?
Here, novelty, feature or functionality of the mobile phone app was achieved using information and techniques available within the technological knowledge base. It did not require a technological advancement.
Lastly, let us now look at the example from scenario 3 where work was undertaken towards achieving a single sign-on capability for their application hosted in XYZ Cloud.
In this project, understanding where and how the Directory Service user object attributes are used in the claims, how they are mapped to the security tokens, their relationships to the Cloud identity management user object attributes and ruling out the need to mimic any Federation Service specific behavior was presented as the technological advancement.
Do you think this statement represents a technological advancement?
The answer here is, yes. Why?
Because this knowledge allowed the building of ‘single sign-on capability without ‘the need to use the XYZ software company’s Federation Service’ in the XYZ Cloud and the creation of user store not based on XYZ Directory Service for single sign-on.
It is important to note that achievement of single sign-on capability on its own is not the technological advancement.
After having looked at technological advancement, we will address question 5 of step1 in the eligibility policy that concerns record of hypotheses tested and the results kept as the work progressed. This is covered through slides 52 to 55.
Why is this important?
This is important for several reasons.
The records confirm that the work described during a review was performed.
It is a record of hypotheses, tests, and results that shows the progress of work.
It reveals the analysis of results from each step and how it is applied to the next step.
It also shows if indicators and measures identified to determine if the goals of the work are being met, are recorded.
Tracking and retaining these records bring out the results of the work.
Using the work undertaken described in a previous example we will illustrate the record of the hypotheses tested and the results kept.
The work described in the previous example on the development of a single sign-on method is made of hypotheses, tests, and results as it progressed.
This is used as an example to provide instances of naturally produced results of testing and organized recording as work progressed:
Confirmation of the visibility of Directory Service user attributes inside the claims within WS-Federation credentials was done using a packet sniffing and analysis tool and therefore the following results would have been naturally or easily produced:
- Screen-capture or log of the responses identifying the tokens with claims, and
- The recognizable attributes of the Directory Service user objects with or without encoding.
The next step to map the attributes to the claim identifiers should produce:
- Names and format of expression of all the claim identifiers and their associated user objects in the claims
The trust association between the generic Security Token Server and XYZ Cloud was set-up and made functional. A screen capture of the response of the appropriate commands used to establish this association will provide the details of what was accomplished.
Finally, code changes were introduced and modified in the generic Security Token Server to enable claim construction. Several tests were conducted and adjustments were made based on the results of the tests to enable successful claims and security tokens. This work should have:
- initial modification to the source code to create claims and the results of using it,
- changes made based on the results of previous tests and their outcome, and
- the final code
We have completed the illustration of SR&ED associated with software development.
Let us summarize the various points covered in this webinar.
Software development has become intrinsic to new or improved products/services in many sectors.
There is prolific and unprecedented development of complex applications using software.
This is driving the need for technological advancement. Technological advancement may be either in software technology or other fields. Within software technology, advancements happen at various levels.
Technology is knowledge and not a physical thing.
The five-question methodology applies to software development as in any other field
Identifying the technological knowledge base properly is important.
Limitation of technology needs to be articulated by correlating it with the technological knowledge base.
Not all systematic work is a systematic investigation or search as required in SR&ED.
By showing why a possible solution will not succeed or will not meet the desired objectives, advancement is still possible.
Record of hypotheses tested and results generated is important for demonstrating that a systematic investigation or search took place.
This brings us to the conclusion of this webinar. Through examples, we have illustrated some of the key concepts associated with the Step 1 of the Eligibility of Work for SR&ED Investment Tax Credits Policy for claims containing software development.
Report a problem or mistake on this page
- Date modified: